Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/terms/kermit/e/v10.2

Text File | 1989-08-20 | 23.5 KB | 524 lines

21-Aug-89 22:01:53-GMT,24015;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA16194; Mon, 21 Aug 89 18:01:51 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
    id AA12585; Mon, 21 Aug 89 17:59:17 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA15908; Mon, 21 Aug 89 17:22:26 EDT
Date: Mon, 21 Aug 1989 17:22:25 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V10 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 21 Aug 1989        Volume 10 : Number 2

Today's Topics:
                  Announcing Pick Kermit Version 0.3
                C-Kermit 4F(094) Available for Testing
                  ISO/Kermit Correspondence Archive
                  File Comparitor for IBM Mainframes
                      CMS Kermit 4.1.001 Warning
          MS-Kermit Scripts and IBM 7171 Protocol Converters
     Using KERMIT for File Transfer Between a PRIME and an RT PC
                      C64-Kermit Problem
                    Re:  Using Kermit on Ethernet?
                         Kermit for Navigator
                    Errors Compiling Amiga Kermit

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2, or to CUNIXC,
CUNIXC.CC.COLUMBIA.EDU, a VAX 8700 running UNIX (Ultrix), IP host number
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET the desired files.  The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e.  You can also get Kermit files
over BITNET/EARN; to get started send a message with text HELP to KERMSRV, the
Kermit file server, at host CUVMA.  For detailed instructions, read the file
kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Mon Aug 21 12:13:32 1989 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing Pick Kermit Version 0.3
Keywords: PICK, Microdata, McDonell Douglas, REALITY, Ultimate, IBM PC

>From Joe Fisher of Austin, Texas, comes release 0.3 of Kermit for the PICK
operating system, written in DATA/BASIC.  Version 0.3 replaces version 0.2C
of January 1987.  The previous release worked only on the Microdata REALITY
system, but the new release works on the following systems:

  Microdata (now McDonell Douglas) REALITY 4.2E
  DEC MicroVAX II with Ultimate Coprocessor R10*182P
  IBM PC/XT and compatibles under PICK R83*2.0
  IBM PC/AT and compatibles under PICK R83*2.2

The source files have been completely recoded and reorganized to be
compatible with Kermit Distribution.  They contain only printable ASCII
characters.  There is a new manual, in PICK Runoff format, PICDOC.RNO,
containing user and installation instructions.

Thanks to Joe for his efforts in preparing and contributing this new
version.  The files are in the D area of Kermit Distribution, under the
prefix PIC (kermit/d/pic*.* on watsun, PIC* * via BITNET KERMSRV).

------------------------------

Date: Mon Aug 21 12:33:41 1989 EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit 4F(094) Available for Testing
Keywords: C-Kermit, UNIX Kermit

The forthcoming new release of C-Kermit 4F is coming closer.  Many of the
problems reported by the beta testers have been solved, but a few more must
be fixed before final release.  Since 4F(085) was announced for testing in
Info-Kermit V10 #1 on July 14th, many changes have been made:

 - attempt to allow the program to compile correctly on Apollo SR10 BSD
 - attempt to fix the crazy echoing upon reconnecting after file transfer
   in AT&T-based Unix systems
 - fix the OS/2-specific code so that it compiles correctly
 - added new support for Masscomp/Concurrent RTU
 - added support for AT&T 6300
 - fix TRANSMIT command to be interruptible by Ctrl-C
 - various minor bug fixes, cosmetic improvements, and code reorganization
 - fix IBM/Rolm CBX dialing
 - fix support for NeXT in the makefile
 - improved support for Hayes modem responses
 - new Microcom modem support
 - updated support for OS-9/68K
 - fixed dynamic packet size recalculation to only shorten packets upon real
   errors
 - fixed file size and throughput reports in STATISTICS command
 - attempt to eliminate many compile-time point-type mismatches caused by
   calls to signal()

Some outstanding problems:

 - The OS/2 version reportedly compiles and runs correctly, but the
   CKOKER.BOO file which is provided is based on a much older version of
   C-Kermit.  OS/2 users who build the new version are encouraged to send in
   an up-to-date CKOKER.BOO file.

 - The VAX/VMS support code (CKV*.*) is not yet updated to agree with this
   version.  The new VMS code should be available within a week or two.

 - Similarly, the Macintosh code is slightly behind this version, and may
   need some reconciliation.

 - Support code for other non-Unix systems such as Commodore Amiga and Data
   General AOS/VS has not been updated in a very long time, and can not be
   compiled with the current version of C-Kermit.

 - BIG PROBLEM: On an AT&T 3B2/300, but apparently nowhere else, C-Kermit
   fails to write out one or more file buffers when receiving files.

 - Many Unix systems now disagree on the data type of the signal() function.
   Previously it was always (*int)(), but now it is (*void)() on some
   systems like AT&T System V R3, SUNOS 4.0, etc.  C-Kermit includes a
   SIGTYP definition in CKCDEB.H to handle this, but this needs to be
   updated to reflect the situation on the many different systems C-Kermit
   tries to support.  So far the only bad effect seems to be compile-time
   warnings about pointer mismatches.

C-Kermit users are urged to get the latest pre-release and try it out on
their systems and report any problems to me, so that this new version can
finally be formally released, and work can begin on the next version.

The files are in kermit/test/ck*.* on watsun, and T:CK*.* on BITNET KERMSRV
at CUVMA.

------------------------------

Date: Mon Aug 21 12:33:44 1989 EDT
From: Christine M. Gianone <[e-mail]>
Subject: ISO/Kermit Correspondence Archive
Keywords: International Character Sets

The mail archive of the "ISO / Kermit" discussion group is now available as
kermit/test/mail.txt on watsun, and as T:MAIL.TXT on BITNET KERMSRV.  The
messages discuss the recent proposal to extend the Kermit protocol for
transfer of text files composed of different national character sets, as
well as the first three drafts of the proposal itself.  Please notify me if
you want to be added to this discussion group.  A fourth draft of the
proposal will be available shortly.

------------------------------

Date: Fri, 1989 May 12   15:16:26 EDT
From: "John F. Chandler" <[e-mail]>
Subject: File Comparitor for IBM Mainframes
Keywords: IBM 370 Kermit

For those who don't already have a favorite file-comparison program, here's a
note concerning one that is available in the Kermit distribution under the
name IK0VER.FOR (that's I K Zero, not I K OH).  It's specialty is comparing
files of 80-byte records with sequence numbers in columns 73 through 80, and
it writes out the differences in the form of an update file for converting one
input file into the other.  The syntax of the updates is compatible with that
used by the UPDATE command of CMS (the control cards begin with the string
"./ " in columns 1-3).  It is not difficult to write a companion program for
applying the updates -- such a program is also available in the Kermit
distribution in versions for MVS, TSO, and MUSIC (in assembler).  IK0VER is
entirely in Fortran and contains comments with directions for converting from
F77 to F66.
                                   John

------------------------------

Date: Tue, 20 Jun 89 15:59:13 EDT
From: Brian Holmes <[e-mail]>
Subject: CMS Kermit 4.1.001 Warning
Keywords: IBM 370 Kermit

After installing version 4.1.001, so far I have only noticed one bug.  When
I invoke the new version I always get the message "Invalid Kermit command"
before I get the CMS-KERMIT> prompt.  I notice that the string '$_' appears
on the screen after I invoke the new version and before I get the error
message.  It appears that '$_' is getting passed to KERMIT somehow and of
course this would generate the error.  I grabbed a completely new version
from KERMSRV before I started too.  Has anyone else had a problem similar to
this?
                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : [e-mail]
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES

[From John Chandler - The message before the Kermit prompt is undoubtedly
due to something in your KERMINI file left over from "the old days".  The
most likely that comes to mind is "SET SERIES1 ON", which was abandoned as
of 4.0 in favor of "SET CONTROLLER SERIES1".  Nearly all the other obsolete
forms of Kermit subcommand are still accepted in Kermit-370, such as "SET
FILE-TYPE BINARY" (should be "SET FILE TYPE BINARY") and "SET RECFM F"
(should be "SET FILE RECFM F").  The "$_" appearing on the screen suggests
something entirely different, namely, that you are connecting through a
fullscreen terminal that isn't Yale-ASCII-type.  Kermit-370 attempts to
detect the kind of terminal controller by issuing a Yale ASCII status
request (which contains an undefined 3270 order plus a dollar sign and
x'BC').  If the controller doesn't recognize the special order as a status
request introducer, the remaining characters will simply appear as text on
the screen.  Kermit will then, incidentally, decide that the controller is
of type GRAPHICS, but it might also be a real 3270-type terminal (in which
case, you wouldn't be able to do any file transfers).  Still, the screen
would normally be cleared after the status check, but some protocol
converters sometimes leave garbage on the screen anyway.]

------------------------------

Date: Fri, 04 Aug 89 09:46:51 ADT
From: [e-mail]
Subject: MS-Kermit Scripts and IBM 7171 Protocol Converters
Keywords: MS-DOS Kermit, Protocol Converters, IBM 7171
Xref: 7171, See IBM 7171

This is in reply to Mike Porter's query in Info-Kermit Digest, v9n7.  Sorry
about the long delay in replying, but because of a BITNET problem, I just
received this issue this week.

We also run IBM7171 protocol converters as the main access to the IBM
mainframes.  I have developed several scripts for automatically logging in,
e.g. to TSO.  In doing that work, I have gained some experience in writing
such scripts.  The following comments might be useful to others:

On a fast PC, it is possible to send a reply to the 7171 too soon (even though
the 7171 is a full duplex device with type ahead buffers).  Apparently, some
software clears the typeahead, e.g. when VTAM turns the terminal over to a new
application.  For example:

   INPUT 10 TERMINAL TYPE:
   OUTPUT vt100\13

starts the output as soon as the colon is received.  Use of Kermit in "line
monitor mode" (set debug on) shows that our 7171 is configured to send a blank
after the colon.  I use

   INPUT 10 TERMINAL TYPE: ;

where the semicolon appears to say that the input string ends at the character
immediately preceding.  Use of backslash code for blank might be better style.
This is particularly important when the 7171 sends an escape sequence (e.g.
cursor positioning) following the visible text.  I have found it frequently
necessary (on my 286 machine) to wait for the escape sequence before sending.
(BTW, escape sequences frequently include semicolons; remember to backslash
escape semicolons in input statements as in:

   input \27[2\;36H

I once spent many hours finding a bug in a script)

The problem of the 7171 sending set-up sequences during the script processing
and these not being transmitted to the emulator is a very annoying one when
trying to automate logons for users.  jrd's proposed solution of:

    set input-echo off
    input 10 terminal type: ;
    output vt100\13
    connect

won't work for us because there is a whole sequence of input/output statements
to do the logon to TSO or whatever before the connect, whereas the 7171
insists on sending the initialization immediately in response to the
"vt100\13".  (Question to jrd: with set input echo off, just how much input is
buffered for eventual processing by the emulator?)

One possible solution would be addition of commands to MS Kermit of the form:

    set terminal vt100-keypad-mode application

or similar.  A script could then anticipate the required setting of all the
emulator modes and explicitly set them before connect.  I can see no way of
doing this in MS Kermit 2.32/A.  (jrd: have I missed something?)

The current workaround is to instruct users to type the "7171 reset" key
(control G on our system) after logging in.  This retransmits all of the vt100
setups while the emulator is listening.  Unfortunately, it is easy for a user
to forget this, which causes strange problems, e.g. in the TSO editor.

I have tried ending scripts with

    output \7
    connect

(yes, with set input-echo off) to try to ask for a reset just before the
connect in the hopes that the emulator would then catch the sequences.  Works
perfectly in the next office on an IBM PC/XT.  On my PS/2 30-286 (an 80286,
10MHz, 1 wait state machine) the communications goes into a loop!  The 7171 is
continuously sending garbage stuff.  I have not had the time to determine
whether the 7171 has botched and is sending junk, or whether MSKermit is
continuously sending stuff and the 7171 is merely responding with error
messages.  (Typically, TSO invalid command, etc).  I presume that the problem
is that the reset occurs too soon after the last part of the logon command to
TSO on my faster machine.  I will report on this problem if I discover more
information.

John DeDourek, Professor
School of Computer Science
University of New Brunswick
Fredericton, N. B. CANADA
E3B 5A3

[e-mail]      -- Registered Domain Name
DEDOUREK@UNB         -- BITNET / NETNORTH (Canada)
[e-mail]  -- For mailers which only know how to get to
                        bitnet this way.

[From jrd - There are two buffers.  The serial port circular buffer is
typically 1500 bytes.  Script commands and the emulator draw from it, and
characters cannot be returned afterward.  Script commands may use a private
128 byte buffer for pattern matching; this buffer is not accessible by the
emulator.  This means that characters drawn out of the primary serial port
buffer by the script commands will not be seen by the terminal emulator.  (To
reiterate a common item: the terminal emulator is not active during scripts,
and this is the root of the discussion here).

I agree that \32 is much safer rendition of a trailing space than a movable
comment indicator. One may also use curly braces around the pattern string,
such as:

   INPUT 10 {TERMINAL TYPE: }           ; optional comment

If one checks DEC VT10x terminals one finds that keypad applications mode can
be set only by the host. The same is true for the VT300 series terminals.
However, the VT320/102/52/H-19 emulator the next release of MS Kermit has the
command SET TERMINAL KEYPAD {NUMERIC, APPLICATION}.

There must be a 7171 problem associated with a too rapid response from the PC.
One way of achieving a tiny wait interval is to say PAUSE 0, the processing
time for which is a few milliseconds.]

------------------------------

Date: 26 May 89 20:22:39 GMT
From: [e-mail]
Subject: Using KERMIT for File Transfer Between a PRIME and an RT PC
Keywords: IBM RT PC, Prime

Concerning using KERMIT for file transfer between a PRIME and an RT:

IT NOW WORKS!

Thanks to everybody who took the time to offer me suggestions, both in the
forum and directly.  I REALLY appreciate it.

It turned out to be a protocol problem -- like the RT version of KERMIT, the
PRIME version also has a KERMIT setup file (that I had been overlooking); so
when KERMIT on the PRIME was made active, it would change the parameters
that I had set using the PRIME's ASYNCH (or whatever) command.

Making sure parity was set to "mark" on both systems is what specifically
fixed the problem.

And to think the only Kermit I knew two weeks ago was the one on Muppet
Babies...

Thanks again for all the help.
-- Mark Skinner (MSKINNER at BOSTON5) 8-234-6521

------------------------------

Date: Tue, 13 Jun 89 22:30:30 EST
From: [e-mail] (Ray Moody)
Subject: C64-Kermit Problem
Keywords: Commodore 64 Kermit, C64 Kermit

>I have the following configuration : a Commodore C64, a 2400 baud Hayes
>compatible modem and a modem adaptor that connects the former two together.
>When I used a terminal software called CCGMS 6.0, the system worked nicely up
>to 2400 baud !!!!!  However, when I used KERMIT, it was a complete failure no
>matter what baud rate I tried !!

    Commodore Kermit is only capable of 2400 baud on a C128, not a
C64.  Support for 2400 baud is likely to appear in the future (hey;
a C64 is a slow machine.)

    There is a problem that occurs at 1200 baud on some modems when
connected to a C64.  The C64 thinks it is a C128 and uses slightly
different timing.  Some modems don't care, others do.  There is a
fixed version of Kermit 2.2, but this version is not widely
distributed.

    There are no known problem with 300 baud.

>The problem is : After the usual procedure
>of dialing the number manually and hearing the high pitch tones, the modem
>did not kick in to do the rest !!  Are there some parameters (that I am not
>aware of) that need to be set beside baud rate in KERMIT ?  What about a
>parameter in KERMIT called rs232-registers ?  What should be its hex value?
>Any help is appreciated !!

    My guess is that there is something *inside the modem* that is not
set properly.  Perhaps you are not sending an AT sequence that your
terminal program does.

    The "set rs232-registers" command is going away soon.  In older
versions of Kermit, the "set rs232-registers" command was used to
specify baud and parity with a cryptic hex number.

    The typical "gotcha" in Commodore Kermit is changing parity
without changing word-size.  If you are using no parity, you should be
using eight bit words.  If you are using any other parity, you should
have seven bit words.  (Perhaps this ``feature'' is too confusing to
be worth keeping.)
                                Ray

------------------------------

Date: Tue, 20 Jun 89  21:16:37 EDT
From: "Roger Fajman" <[e-mail]>
Subject: Re:  Using Kermit on Ethernet?
Keywords: Ethernet

> [Ed. - There are many requests for this.  The most practical approach to
> adding TCP/IP Telnet support to MS-Kermit would be to take the board-level
> drivers from NCSA Telnet and convert them into TSR Bios-level drivers for
> COM1.  Then let MS-Kermit's SET PORT BIOS1 command do the rest.  This
> apparently already works with certain commercial IP products, e.g. Interlan's
> TCP/IP Gateway for Novell networks (see Info-Kermit V9 #8).]

FTP Software recently announced INT 14 support for their PC/TCP product,
which supports many network boards.  I haven't had an opportunity to try it
with MS Kermit yet.

------------------------------

Date: Sat, 03 Jun 89 18:01:01 EDT
From: Peter Jones <[e-mail]>
Subject: Kermit for Navigator
Keywords: Navigator, Blind, Braille

Some time ago, I announced I would be interested in developing a KERMIT
system for the VBII terminal for the blind, an 8080-based braille
workstation. I have decided to abandon this project, as too much investment
would be required to support and debug an 8080 program in our environment.

Telesensory Systems Inc has announced a new device called the Navigator.
This is a PC-like system with braille I/O. As we use PC's at UQAM, support
would be available. I'm wondering if anyoune has tried Kermit on the
Navigator.  Would a special version be required?

Peter Jones     MAINT@UQAM     (514)-282-3542
"All's well that ends." :-)

------------------------------

Date: Fri, 21 Apr 89 09:16:59 MET
From: "Boelen, Lodewijk J.M." <[e-mail]>
Subject: Errors Compiling Amiga Kermit
Keywords: Amiga C-Kermit, Commodore Amiga

     Lectori Salutem

In December I have got both the sources and a BOO-ed version of Kermit on my
Amiga.  By curiosity I compiled the sources with the Lattice 3.10 compiler
to get acquainted with the software available on my new (second hand)
AMIGA2000.  I love that machine!

I remarked the following compiletime errors:
  1.there are many warnings 89 on the variables "pid" and "D7Save" and others;
  2. ckitio.c:
    .1 error 71: formal declaration error "m";
    .2 error 9: undefined identifier "m";
    .3 error 63: duplicate declaration of item "m";
  3. ckifio.c: error 57: semicolon expected;
  4. ckuus3.c: error 25: invalid macro usage.

The total time needed for compilation on my two-diskette machine, with an
adapted make-file, is 15 minutes.  On scanning the sources near the marked
lines I made some changes I will describe hereafter.  All the compiletime
errors were gone but the one in ckuus3.c.

To get a Kermit program I had to attack the BOO-ed version I guessed to be
in ckiker.upd.  When anyone is interested I will mail my critics and the way
I got a working Kermit program.  I could emulate a terminal, that's all.  I
called for HELP but got no responses on the sources problems.

So I waited for the newest version, announced in the meanwhile, hoping on
the errors to be corrected.  Before yesterday I compiled the newest sources
the first time.  I was sad to find the same errors as described above plus
one: the version of HEARN's ckucmd.c is cut off.  After receiving the
TUVMA-version and applying the corrections, yesterday I got in the same
situation as in January.  So now my second call for HELP!

Here are the corrections on the lines of the actual version:
  1. ckitio.c: all the errors are gone when you change line 692 from:
    "int n, m;" into: "int n;" and insert after line 695: "int m;";
  2. ckifio.c: a little above line 343 you can find: "return(...));". If you
    change this line in "return(...);" (one ")" less!) all is well.

I don't know C though it looks very nice, but also a colleague could not find
a solution on the error in ckuus3.c.

I wonder if the warnings are not harmful, but I don't know to correct them.

Can anyone help me? I would be grateful,

      Lodewijk.

[Ed. - To our knowledge, nobody has worked on the Amiga-specific portion of
C-Kermit since Steve Walton's contributions of January 1987, listed in
ckiker.upd.  If anyone out there has worked on upgrading C-Kermit's Amiga
support to the current version of C-Kermit -- or better still, the test
version 4F with file attribute packets -- please let us know!  Or if you are
willing to volunteer to take on the job, also please tell us.  Until then,
the best we can do is add Lodewijk's message to the ckiker.bwr file.]

------------------------------

End of Info-Kermit Digest
*************************